@jan-janssen, the quantum espresso demo holds input lists of int and float. It looks to me like these should be replaced by kmesh(kx: int, ky:int, kz:int) and range(start: float, end: float, steps: int) (or similar) nodes.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@liamhuber I am open to clarifying an implicit restriction that we practically already used but did not enforce so far. But I am a bit more reluctant to modify the examples after publication as I feel this would break backwards compatibility. This is would require a 2.0 release.

Better to use #167 as the starting point if you're going to do this, the test suite is more complete

Better to use #167 as the starting point if you're going to do this, the test suite is more complete

I am happy to merge the additional tests in #167 as well.

Better to use #167 as the starting point if you're going to do this, the test suite is more complete

I am happy to merge the additional tests in #167 as well.

I disapprove of this change, but if you're going to make it anyway then the extra tests are a positive.

@liamhuber I know that we disagree on the extend of the changes to the pydantic class - in particular in terms of allowing dictionaries as default - still I would like to merge this pull request as I see it as an improvement to the current version on the main branch, unless you strongly disagree.

@liamhuber I know that we disagree on the extend of the changes to the pydantic class - in particular in terms of allowing dictionaries as default - still I would like to merge this pull request as I see it as an improvement to the current version on the main branch, unless you strongly disagree.

I agree that some constraint is an improvement on no constraints. However, I can't approve this PR in its current form. I'm not an org member here nor a repo maintainer, so merging it is your prerogative, but it's against my recommendation.